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Abstract 


This document specifies the exact documents that make up the complete 
Dynamic Delegation Discovery System (DDDS). DDDS is an abstract 
algorithm for applying dynamically retrieved string transformation 
rules to an application-unique string. 


This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 
2168 and RFC 2915, as well as updates RFC 2276. 


1. Intended Audience 


This document and the documents that it references are intended for 
anyone attempting to implement or understand the generic DDDS 
algorithm, URI Resolution, ENUM telephone number to URI resolution, 
and the NAPTR DNS resource record. The reader is warned that reading 
one of the documents in this series without reading the others will 
probably lead to misunderstandings and interoperability problems. 


2. Introduction 


The Dynamic Delegation Discovery System is used to implement lazy 
binding of strings to data, in order to support dynamically 
configured delegation systems. The DDDS functions by mapping some 
unique string to data stored within a DDDS Database by iteratively 
applying string transformation rules until a terminal condition is 
reached. This document defines the entire DDDS by listing the 
documents that make up the complete specification at this time. 
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This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes 


RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5]. This 
document will be updated and or obsoleted when changes are made to 
the DDDS specifications. Thus the reader is strongly encouraged to 


check the IETF RFC repository for any documents that obsoletes or 
updates this one. 


3. The Algorithm 


The DDDS algorithm is defined by RFC 3402 [1]. That document defines 
the following DDDS concepts: 


o The basic DDDS vocabulary. 

o The algorithm. 

o The requirements on applications using the algorithm. 
o The requirements on databases that store DDDS rules. 


RFC 3402 is the actual DDDS Algorithm specification. But the 
specification by itself is useless without some additional document 
that defines how and why the algorithm is used. These documents are 
called Applications and do not actually make up part of the DDDS core 
specification. Applications require databases in which to store 
their Rules. These databases are called DDDS Databases and are 
usually specified in separate documents. But again, these Database 
specifications are not included in the DDDS core specification 
itself. 


4. DDDS Applications 
No implementation can begin without an Application specification, as 
this is what provides the concrete instantiation details for the DDDS 
Algorithm. Without them the DDDS is nothing more than a general 


algorithm. Application documents define the following: 


o the Application Unique String (the thing the delegation rules act 
on). 


o the First Well Known Rule (the Rule that says where the process 
starts). 


o the list of valid Databases (you can’t just use any Database). 


o the final expected output. 
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Some sample Applications are documented in: 


o "E.164 number and DNS" (RFC 2916) [7]. This Application uses the 
DDDS to map a telephone number to service endpoints such as SIP or 
email. 


o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform 
Resource Identifiers (URI) Resolution Application" (RFC 3404) [3]. 
This Application uses the DDDS to resolve any URI to a set of 
endpoints or ’resolvers’ that can give additional information 
about the URI independent of its particular URI scheme. 


5. Currently Standardized Databases 


Any DDDS Application must use some type of DDDS Database. Database 
documents define the following: 


o the general spec for how the Database works. 

o formats for Keys. 

o formats for Rules. 

o Key lookup process. 

o rule insertion procedures. 

o collision avoidance measures. 

A Database cannot be used on its own; there must be at least one 

Application that uses it. Multiple Databases and Applications are 

defined, and some Databases will support multiple Applications. 

However, not every Application uses each Database, and vice versa. 

Thus, compliance is defined by the combination of a Database and 

Application specification. 

One sample Database specification is documented in: 

o "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain 
Name System (DNS) Database" (RFC 3402) [1]. (This document is the 
official specification for the NAPTR DNS Resource Record.) 

6. Security Considerations 

Any known security issues that arise from the use of algorithms and 

databases must be specified in the respective specifications. They 


must be completely and fully described. It is not required that the 
database and algorithms be secure or that it be free from risks, but 
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that the known risks be identified. Publication of a new database 
type or algorithm does require a security review, and the security 
considerations section should be subject to continuing evaluation. 
Additional security considerations should be addressed by publishing 
revised versions of the database and algorithm specifications. 


7. IANA Considerations 


While this document itself does not create any new requirements for 
the IANA, the documents in this series create many varied 
requirements. The IANA Considerations sections in those documents 
should be reviewed by the IANA to determine the complete set of new 
registries and requirements. Any new algorithms, databases or 
applications should take great care in what they require the IANA to 
do in the future. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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